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Vorwort 


Das vorliegende Schulungsnaterial wurde für den Lehrgang 
"POS-Teochnologie -— System- und Programmentwurf" erarbei- 
tet. 


Das Material besteht aus drei Teilen s 


Teil 13 Teohnologisches Konzept, 
Teil 23 Methoden und Techniken, 
Teil 3: Aufgaben. 


Im Teil 1 wird ein teohnologisches Konzept für den Ent- 
wurf problemorientierter Systemunterlagen (POS) vorge- 
stellt, 


Wesentliche Methoden und Techniken des Entwurfs sind im 
Teil 2 beschrieben, 


Eine Aufgabensammluıng (Teil 3) enthält Aufgaben, welche 
im Prozeß der Lehrgangsdurchführung zu lösen sind, 


Anmerkung: 
Literaturhinweise werden während der Lehrgangsdurchfthrung 
gegeben. 


1°. Technologisches Konzept zur Entwicklung problem- 
orientierter Systemunterlagen 


1.1. Problemorientierte Systemunterlagen (POS) 


Problemorientierte Systemunterlagen sind anwendungsorien- 
tierte, funktionelle und programmtechnische Lösungen bzwe 
Teillösungen von Datenverarbeitungsaufgaben. 


POS werden mit dem Ziel entwickelt, mit hohem ökonomischen 
Nutzeffekt und geforderten Gebrauchseigenschaften in be- 
etimmten Anwendungsbereichen zur Rationalisierung von Lei- 
stungs- und Leitungsprozessen eingesetzt zu werden. 


Typische Formen problemorientierter Systemunterlagen sind 
Datenverarbeitungsprojekte, einzelne Anwendungsprogramme, 
Programnsysteme und Programmpakete., 





1.2. POß-Entwicklungstechnologie als Rahmentechnologie 


Der Begriff "Technologie" hat seinen Ursprung in der Be- 
schreibung von Produktionsprozessen. 


In diesem Zusammenhang soll unter dem Begriff "Technologie" 
aus pragmatischer Sicht eine Beschreibung jener Arbeitsgänge 
und Verfahren verstanden werden, welche im Prozeß der Ferti- 
gung von Produkten mit bestimmten Eigenschaften aus vorhan- 
denen Ausgangsstoffen unter ökonomisch günstigen Bedingungen 
anzuwenden sind. 


Eine Technologie ist Resultat technologischer Untersuchungen. 
Die Untersuchungen können mit unterschiedlichen Zielstellun- 
gen durchgeführt werden. 

Beispielsweise kann eine Untersuchung darauf zielen, eine 
Technologie für einen speziellen - unter konkreten Bedingun- 
gen ablaufenden - technologischen Prozeß zu erarbeiten. 

Die Technologie gilt denn nur für diesen (z.B. betriebsspe- 
zifischen) Prozeß. 


Eine andere Untersuchung hat zum Ziel, von konkreten Beiin- 
gungen unterschiedlicher technologischer Prozesse zu abstra- 
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hieren, das Allgemeingültige und Wesentliche dieser Prozesse 
zu ermitteln und in einer Technologie zu fixieren. Eine der- 
artige Technologie heißt Rahmentechnologie. 

Ziel jeder Technologie ist eine effektive Prozeßgestaltung. 


Hervorzuheben ist die integrierende Funktion der Technologie. 
Sie vermittelt zwischen dem "WAS", dem "WORAUS", dem "WIE" 
und dem "WOMIT" des jeweiligen technologischen Prozesses. 


Folgende Fragestellungen. sind relevant: 


1. WAS wird mit welchen Qualitätsmerkmalen WORAU& 
gefertigt? 

2. WIE erfolgt die Fertigung und Qualitätsprüfung? 

3. WOMIT wird gefertigt und geprüft? 


Versuchen wir, den Technologiebegriff sinngemäß auf den Ent- 
wicklungsprozeß problemorientierter Systemunterlagen zu über- 
tragen. Dabei gehen wir von den genannten Fragestellungen 
ause 


Die erste Frage führt zur Bestimmung des Produkts einschlieB- 
lich der wesentlichen Qualitätsmerkmale sowie zur Bestimmung 
des "WORAUS". 

Mit Beantwortung der zweiten Frage wird eine Bestimmung des 
Fertigungsablaufs, der zugrunde liegenden Fertigungsprinzi- 
pien sowie der anzuwendenden Fertigungs- und Prüfverfahren 
gegeben. 

Die dritte Frage führt zur Bestimmung der Arbeitsmittel. 


Zur ersten Frage: 





WAS WORAUS Wesentliche Qualitäts- 
merkmale des Produkts 

POS Ziel- und Aufgaben- Benutzerfreundlichkeit, 

als Produkt stellung zur POß- Zuverlässigkeit, 

eines Entwicklung Fehlerfreiheit, 

Entwicklungs- (Pflichtenheft) Lesbarkeit, 


prozesses Änderungsfreundlichkeit. 
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Somit ist der Rahmen des POS-Entwicklungsprozesses festge- 
legt: 


Ziel- und Aufgabenstellung zur POS-Entwicklung 
















WORAUS 
WIE 
WOMIT 
Funktionsfähige POS mit geforderten Qualltäts- | WAS 
merkmalen 
Zur zweiten Frage: 
WIE mit Hinblick auf führt zur Bestimmung 
Fertigungsablauf typischer POS-Entwicklungs- 
phasen und Arbeitsschrittfol- 
gen, 
Fertigungs- wesentlicher POS-Entwicklungs- 
prinzipien prinzipien, 
Fertigungs- und typischer Verfahren, Methoden 
Prüfverfabren und Techniken zur POS-Entwick- 


lung und -Prüfung (Test). 


Zur dritten Frage: 





WOMIT mit Hinblick auf fübrt zur Bestimmung 
Gerätetechnik technischer Mittel zur POS-Ent- 
wicklung, 
Programmınter- programmtechnischer Mittel zur 
stützung POS-Entwicklung 


einschließlich -Test: 
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Aus der Beantwortung der "WAS-/WORAUS-Frage” sowie aus der 
Bestimmung der "WIE-/WOMIT-Beziehung” werden Ziel und Gegen- 
stand der POS-Entwicklungstechnologie abgeleitet: 


Ziel der POS-Entwicklungstechnologie ist eine rationelle und 
effektive Gestaltung des POS-Entwicklungsprozesses auf hohem 
technologischen Niveau. 


Gegenstand der POS-Entwicklungstechnologie sind die Bestim- 
mung eines rationellen Ablaufs des Entwicklungsprozesses so- 


wie die Prinzipien, Methoden, Techniken und Nittel zur Ent- 
wicklung problemorientierter Systemunterlagen mit geforder- 
ten Gebrauchseigenschaften unter ökonomisch günstigen Bedin- 
gungen» 


1.3. Prinzipien, Methoden und Mittel zur POS-Entwicklung 


Ein Prinzip ist ein allgemeingültiger Grundsatz, der aus der 
Verallgemeinerung von Gesetzen und wesentlichen Eigenschaf- 
ten der objektiven Realität abgeleitet ist und sowohl in der 
theoretischen Arbeit als auch im praktischen Verhalten als 
Leitfaden dient. 


Wesentliche Prinzipien der POS-Entwicklung sind beispiels- 

weise: 

- Prinzip der Abstraktion (Abstraktionsstufenkonzept), 

- Prinzip der Steuerflußdisziplinierung, nn 

- Prinzip der entwicklungsbegleitenden, prozeßschritt- 
haltenden Dokumentation, des Tests sowie der Verwal- 
tung der Entwicklungsergebnisse, 

- Prinzip der Rechnerunterstützung im POS-Entwicklungs- 
prozeß. 


Eine Methode ist ein System von Regeln, welches mögliche 
Handlungsfolgen festlegt, die von bestimmten Ausgangsbedin- 
gungen zu einem bestimmten Ziel führen. 

Wesentliche Methoden der POS-Entwicklung sind beispielsweise: 


- kethode der funktionellen hierarchischen Dekomposition, 
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- Methode der strukturierten Programmierung, 
- Methode des datenorientierten Programmentwurfs 
nach JACKEON. 


Ein Mittel wird aufgrund bestimmter Eigenschaften vom Men- 
schen benutzt, um einen bestimmten Zweck zu realisieren (Re- 
lation "Subjekt - Mittel - Zweck"). 


Mittel zur POS-Entwicklung sind: 


- technische Mittel und 
- programmtechnische Mittele 


Als technische Mittel zur POS-Entwicklung werden bevorzugt 
“Perminals (Dialogarbeitsplätze) zum Einsatz kommen. 


Einsatzvarianten für Dialogarbeitsplätze sind: 


- Dialogarbeitsplätze an einem Programmentwicklungs- 
rechner (Prinzip: Programmentwicklung nicht auf 
Zielrechner, sondern für Zielrechner), 

- Dialogarbeitsplätze in on-line-Kopplung mit Ziel- 
rechner und dessen Ressourcennutzung zur Programm- 
entwicklung (Prinzip: Teilnehmerbetrieb). 





Programmtechnische Mittel gewährleisten den Einsatz techni=- 
scher Mittel zur POS-Entwicklungs 


Nutzbar sind beispielsweise 


- Programgeneratoren, 

- Testdatengeneratoren, 

- Textaufbereitungs- und Dokumentationsprogramme, 
- Vorübersetzer. 
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2e Phasenmodell zur POS-Entwicklung 


2.1. Konzept zur Phasenbestimmung (Abstraktionsstufenkonzept) 


® 
Die Komplexität problemorientlierter Systemunterlagen führt 
im POS-Entwicklungsprozeß häufig zu folgendem Dilemma: 


Einerseits ist erforderlich, die POS-Architektur und -be- 
schreibung so einfach wie möglich zu gestalten (Voraussetzung 
für das Verständnis), andererseits dürfen die vielfältigen 
POS-Charakteristika und Details nicht vernachlässigt werden. 


Ein Ausweg aus dem Dilemma wird in einer hbierarchischen POS- 
Architektur und einer entsprechenden Phasengliederung des 
POS-Entwicklungsprozesses gesehen. 

Die dazu relevanten theoretischen Grundlagen sind in Diszi- 


plinen wie Systemtbeorie und Systemtechnik zu finden (z.B» 
bei MESAROVIC). 


wir betrachten ein System 6: X—> Y, dessen Funktion als Ab- 
bildung einer Menge von Eingangsgrößen X in eine Menge von 
Ausgangsgrößen Y definiert ist. 


Angenommen wird, 

daß zwei Mengenfemilien X, und Y, (i = 1,2,°°.,n) vorbanden 
sind und sich die Mengen X und Y als kartesische Produkte 

X = X, x X, X oo X Xn und Y= I, x Y, X oe. X Yn 
darstellen lassen. 

Diese Annahme eröffnet die Möglichkeit der Aufspaltung der 
Eingangsgrößen X und der Ausgangsgrößen Y in Komponenten. 


Jedes Paar (x, ; L,) i = 1,2,00.,D, charakterisiert ein und 
dasselbe Bynken 6 vom Standpunkt unterschiedlicher Abstrak- 
tions- und Beschreibungsniveaus (Mehrebenenarchitektur; 
"stratifiziertes System"). 


Für Jede Ebene lassen sich bestimmte Gesetzmäßigkeiten, Prin- 
zipien und charakferistische Merkmale angeben, durch welche 
das System beschrieben werden kann. 
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Eintritt in Ebene i 
(i=1 Pr ‚n) 


Prinzipien 
Sicht n Methoden,Mittel, 
EBENE n Sprache(n) 











Sicht i+1 





EBENE i+1 





Sicht i-1 





Sicht 1 
® EBENE 1 
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Abgeleitete Aussagen: 


1e 


2 


3° 


4. 


5. 


6. 


7. 


8. 


9%. 


Die Auswahl der Abstraktions- bzw. Beschreibungsniveaus 
(Ebenen) wird von objektiven Erfordernissen und subjek- 
tiven Aspekten bestimmt. Sle ist weitgehend abhängig vom 
Standpunkt des Betrachters, von dessen Kenntnissen und 
dessen Interesse an bestimmten Aspekten des Systenverhaltens 
und einer entsprechenden Systemmodellierung. 


Die Detailliertheit und das Systemverständnis verhalten 
sich, über mehrere Ebenen betrachtet, umgekehrt propor- 
tionale 


Jede Ebene repräsentiert eine bestimmte Sicht, welche der 
£ystembeschreibung zugrunde liegt. 


Die Aspekte der Systembeschreibung auf unterschiedlichen 
Ebenen sind im allgemeinen voneinander unabhängig. Folg- 
lich müssen Gesetzmäßigkeiten und Prinzipien, welche für 
die Charakterisierung eines Systems auf einer bestimmten 
Ebene relevant sind, nicht obne weiteres für andere Ebenen 
von Bedeutung sein. 


Jeder Ebene können bestimmte, niveauspezifische Prinzipien 
und Methoden sowie Mittel zur Systembeschreibung (z.B. 
Sprachen) zugeordnet werden. 


Beschreibungsobjekte einer jeden Abstraktionsebene sind im 
wesentlichen Daten und deren Verarbeitungsprozesse, spezi- 
fiziert durch Operationen, welche mit den Daten ausgeführt 
werden könnens 


Die mit sprachlichen Mitteln einer bestimmten Ebene ausge- 
führte Systembeschreibung kann durch Transformation in ei- 
ne entsprechende Beschreibung überführt werden, welche ei- 
ner anderen Ebene zugeoränet ist. 


Die Transformation kann rechnerunterstützt erfolgen (Goft- 
wareschicht). 


Das Abstraktionsstufenkonzept wird als Ausgangspunkt zur 
Bestimmung von Phasen der POS-Entwirklung gewählt. 
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2.2. POS-Entwicklungsphasen 


Der Rahmen für die Begrenzung des POS-Entwicklungsprozesses 
wurde im Abschnitt 1.2. festgelegt. 


Die Ziel- und Aufgabenstellung zur POS-Entwicklung entsteht 
als Ergebnis einer Analysephase (Pflichtenheft). In präzi- 


sierter Form ist sie Eingangsgröße für den F0S-Entwicklunge- 
prozeßB. 


Funktionsfähipge POS sind Ergebnis des Ey&wicklungsprozesses. 
Sie werden in den AÄnwendungsbereich übergeleitet und im 
Dauerbetrieb genutzt. 


Zwischen Ziel- und Aufgabenstellung und funktionsfähiger POS 
besteht eine Kluft, die im allgemeinen eine direkte Überbrük- 
kung erschwert. 


Die Anwendung des Abstraktionsstufenkonzepts für den POS-Ent- 
wicklungsprozeß führt zur Bestimmung relevanter Prozeßphasen 
und somit zur Überbrückung der genannten Kluft. 


Entsprechend dem gegenwärtigen Erkenntnisstand werden im Pro- 
zeß der POS-Entwicklung unterschieden: 
- eine Entwurfspbase, 
- eine Implementierungsphase, 
- eine Phase der POS-Erprobung (Funktionstest) 
mit anschließender Überleitung in den Anwendungsbereich. 


Eine Analysephase ist den Entwicklungsphasen vorgelagertj 
eine Phase der POS-Anwendung und -Wartung ist nachgelagert« 


Die genannten Phasen sind allgemeingültig und von spezifi- 
schen methodischen und gesetzlichen Regelungen weitgehend un- 
abhängig. 


Für die Gestaltung des Prozesses der POS&-Entwicklung in der 
DDR sind insbesondere zu beachten: 
- Rahmenmethodik der Datenverarbeitungspro Jektierung 
und deren Ergänzungen, 
- Nomenklatur der Arbeitsstufen (E-Stufen). 
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Die Zuordnung der Phasen zu den DDR-spezifischen methodi- 
schen Regelungen ist wie folgt darstellbar: 





Phase Zuordnung 

mm rn nn Bam nn Bm nn mn nn nn nn nn nn nn nn —————_—_ —_—_—___——__ 

ANALYSE - Vorbereitende Untersuchungen 
zur EDV-Anwendung (Vorprojek- 
tierung) 


- Arbeitsstufe PM 











ENTWURF - Arbeitsstufe E2 Prozeß 
- Arbeitsstufe E3 der 
PO3= 
IMPLEMENTIERUNG - Arbeitsstufe E4 Entwicklung 
ERPROBUNG (TEST) - Arbeitsstufe ES 





ANWENDUNG UND WARTUNG - Stabiler Dauerbetrieb (E6) 
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Eine phasenbezogene Darstellung des Prozesses der POß-Ent- 





wicklung kann somit wie folgt vorgenommen werden; 


£icht: 
Prinzipien, 
Methoden, 
Mittel, 
Sprache(n) 


PRÄZISIERTE ZIEL- UND AUFGABEN- 
STELLUNG ZUR POS-ENTWICKLUNG 


POS-ENTWURF 

Funktionelle Lösung der Ziel- und Aufgaben- 
stellung hinsichtlich Datenstrukturen und 
Verarbeitungsprozesse 


POS-IMPLEMENTIERUNG 
Daten- und programmseitige Realisierung des 
POS-Entwurfs 


POS-ERPROBUNG (TEST) 
Funktionstest der POS unter Anwendungsbedin- 


gungen (Probebetrieb) 





FUNKTIONGFÄHIGE POS 
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3. Die Entwurfspbase 


3.1. Gegenstand des Entwurfs 


Gegenstand des Entwurfs ist Strukturierung. 
Zu strukturieren sind 
- komplex vorgegebene Aufgabenstellungen 
(z.B. betriebswirtschaftlicher Art), 
- Datenmengen, 
- Verarbeitungsprozesse. a 
F 
Eine Strukturierung hinsichtlich "Aufgabe" führt zu einer 
Aufgabenstruktur: Die einzelnen Aufgabenstrukturkomponenten 
sind zu bestimmen, das Beziebungsgefüge der Komponenten ist 
festzulegen. 


Eine Strukturierung hinsichtlich Daten und Verarbeitungspro- 
zesse läßt mehrere Sichten zu (Dialektik "Teil - Gesamtheit"): 


a) Teilsicht 
Für jede Aufgabenstrukturkomponente (Einzelanwendung;) 
werden Ein- und Ausgabedaten spezifiziert (Datenstruktur) 
und die erforderlichen Verarbeitungsprozesse (Algorithmen) 
in strukturierter Form beschrieben. 


b) Gesamtsicht 
Die Gesamtheit der Daten und die Gesamtheit der Verarbei- 
tungsprozesse sind zu strukturieren. 





Strukturierung 

hinsichtlich führt zur 

Daten Datenstruktur 
Verarbeitungsprozeß Programm- bzw. Programmsysten- 


struktur 


3.2. Abgrenzung der Entwurfsphase 


Zur Abgrenzung der Entwurfsphase bestimmen wir die Schnitt- 
stellen zwischen Analyse und Entwurf sowie zwischen Entwurf 
und Implementierung. 
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Jede der Schnittstellen kann durch eine Beziehung "Ergebnis/ 
Voraussetzung" charakterisiert werden: Ergebnis der Analyse- 
pbase ist Voraussetzung für den Entwurf; Ergebnis der Ent- 
wurfsphase ist Voraussetzung für die Implementierung. 


Schnittstelle Analyse/Entwurf 
Die Ziel- und Aufgabenstellung (Pflichtenbeft) ist Ergebnis 


der Analysephase;, in präzisierter Form ist sie Entwurfsvor- 
eussetzunge 


Schnittstelle Entwurf/ Implementierung 

Datenstrukturen. und Spezifikation der Verarbeitungsprozesse 
sind die wesentlichen Ergebnisse der Entwurfsphase. Diese Er- 
gebnisse sind Voraussetzung für die Implementierung. 


30.3. Entwurfsniveaus 


Abgeleitet aus dem Abstraktionsstufenkonzept sollen im Ent- 
wurfsprozeß zwei Niveaus unterschieden werden: ein logisches 


und ein physisches Entwurfsniveau. 


Die Grundidee der Unterscheidung besteht darin, auf einer 
ersten Stufe eine funktionelle, implementierungsunabhängige 
Lösung der Aufgabenstellung zu entwickeln und diese Lösung 
auf einer zweiten Stufe unter Aspekten der Implementierung 
zu präzisieren. 


Entwurfsniveau Kennzeichnung 





Logisches Entwurfsniveau Die im Entwurfsprozeß entwickelten 
bzw. angewendeten Datenmodelle und 
Algorithmen sind von Hardware- und 
Softwarecharakteristika des Ziel- 
rechners weitestgehend unabhängig. 


Physisches Entwurfs- Daten- und programmseitige Orien- 
niveau tierung auf Hardware- und Software- 
möglichkeiten . des Zielrechners. 
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304. Entwurfsstrategien 


Entwurfsstrategien bringen unterschiedliche Vorgehensweisen 
des POS-Entwurfs zum Ausdruck. 

Sie haben zum Ziel, die Kluft zwischen komplex vorgegebenen 
Aufgabenstellungen zur POS-Entwicklung und den zur Realisie- 
rung einer programmtechnischen Lösung verfügbaren Elementar- 
komponenten bzw. -operationen zu überbrücken. 


Strategie 1: 

Ausgangspunkt: Aufgabenstellung zur POS-Entwicklung (Kom- 
plexität) 

Vorgehen: Reduzierung der Komplexität durch bierarchi- 
sche Dekomposition und fortschreitende Ent- 
wurfsverfeinerung solange, bis verfügbare 
Elementarkomponenten bzw. -operationen an- 
wendbar sind, durch welche die gegebene Auf- 
gabenstellung programm- und datenseitig er- 
füllt wird. 


Varianten: Top-down design, 
Outside-in design. 


Strategie 2: 

Ausgangspunkt: Aufgabenstellung zur POS-Entwicklung (Kom- 
plexität) 

Vorgehen: Fortschreitende, hierarchische Komposition 
verfügbarer Elementarkomponenten bzw. -ope- 
rationen solange, bis die gegebene Aufgaben- 
stellung programm- und datenseitig reali- 
siert ist. 


Varianten: Bottom-up design, 
Inside-out design. 
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305. Entwurfsprinzipien 
3.5.1. Prinzip der Steuerflußdisziplinierung 


Zur Entwicklung strukturierter Programme orientieren wir auf 

das 

- Konzept zur Beschränkung der Anweisungen zur Progremnm- 
ablaufsteuerung (Anwendung von Grundstrukturen) sowie auf 
das 

= Blockkonzept. 


Die Anwendung vereinbarter Grundstrukturen zur Ablaufsteue- 
rung von Verarbeitungsprozessen sowie die Anwendung des 
Blockkonzepts zur Reibung und Schachtelung von Programmstruk- 
turkomponenten gewährleisten den Entwurf und die Implementie- 
rung strukturierter Programme. 


3.5.2. Prinzip der entwurfsbegleitenden Tätigkeiten 

Im Prozeß des schrittweisen Entwerfens fassen wir Recherchie- 
ren, Testen, Dokumentieren und Verwalten als entwurfsbeglei- 
tende Tätigkeiten auf. 

Recherchiert wird in zentralisierten Fonds (im Sinne: Pro- 
jekt- und Programmzentralen, Aufgabenbanken, Methodenbanken, 
Algorithmenbanken, Programmbanken) nach wiederverwendbaren 
Lösungen bzw. Teillösungen von Datenverarbeitungsaufgaben. 
Getestet, dokumentiert und verwaltet werden Ergebnisse bzw. 
Teilergebnisse des Entwurfsprozesses. 





305.3. Prinzip der Rechnerunterstützung im EntwurfsprozeB 


Wir orientieren darauf, eine Reihe von Tätigkeiten im Ent- 
wurfsprozeß rechnerunterstützt an Dialogarbeitsplätzen auszu- 
führen: Datenstrukturen und Verarbeitungsprozesse sind 
schrittweise im Dialog zu entwerfen; die entsprechende Doku- 
mentation ist rechnerunterstützt zu erstellen; Teilergebnisse 
des Entwurfsprozesses sind rechnerunterstützt zu verwalten; 
Generatorprinzipien sind zur Implementierung zu nutzen. 
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Diese Orientierung basiert auf dem Konzept individueller Pro- 


grammentwicklungsbibliotheken sowie auf einer Nutzung dialog- 
orientierter Programmkomponenten. 


Bei on-line-Kopplung der Dialogarbeitsplätze mit EDVA des 
ESER sind das Betriebssystem SVM/ES oder die Betriebssysten- 
komponente T60 (time sharing option - Teilnehmerunterstüt- 
zung) des OS/ES zur Dialogarbeit nutzbar. 


3.6. Methoden und Techniken des Entwurfs 


Entsprechend dem gegenwärtigen Erkenntnisstand werden folgen- 
de Methoden und Techniken bevorzugt im Entwurfsprozeß genutzt 
(Aufzählung ist keine Rangordnung): 


- HIPO (Hierarchy plus Input-Process-Output), 
Datentabellen, 

Entscheidungstabellen, 

Pseudokodes, 

Struktogramme (NASSI-SHNEIDERMAN -Diagramme), 
Datenorientierter Programmentwurf nach JACKSON, 
Methoden zur Datenstrukturierung. 


In der Praxis werden vielfach die Begriffe "Methode" und 
"Technik" synonym verwendet (Beispiel: HIPO-Methode, HIPO- 
Technik). 


Wir wollen zwischen Methode und Technik unterscheiden. 


Der Begriff "Methode" orientiert auf die Art und Weise des 
Vorgehens zum Erreichen eines bestimmten Ziels im Entwurfs- 
prozeß (vgl«» Abschn. 1.3.). 

Den Begriff "Technik" verwenden wir im Zusammenhang mit for- 
malisierten Darstellungen der Entwurfsergebnisse. 


Im allgemeinen schließen die Entwurfsmethoden Techniken zur 
formalisierten Darstellung der Entwurfsergebnisse bzw. -teil- 
ergebnisse eine 
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2. Arbeitsschritte des Entwurfs und Methodenzuordnung 


4.1. Aufgabendekomposition 

Die Aufgabendekomposition erfolgt in zwei Schritten: 
a) der Aufgabenstrukturierung, 
b) der Teilsufgabenbeschreibung. 


4.1.1. Aufgabenstrukturierung 


Eine durch Ziel- und Aufgabenstellung inhaltlich abgegrenzte, 
komplexe Aufgabe zur EDV-Anmwendung wird derart in Teilaufga- 
ben zerlegt (Reduktion der Aufgabenkomplexität), daß sie 
durch die gebildeten Teilaufgaben vollständig repräsentiert 
wird. Die Zerlegung wird solange fortgesetzt, bis sich Teil- 
aufgaben ergeben, deren weitere Untergliederung nicht erfor- 
derliich oder nicht möglich ist. 


Die Dokumentation der Aufgabenstruktur erfolgt als Struktur- 
diagranm (vgl. HIPO). 


Die Identbegriffe der Aufgabenstrukturkomponenten werden bei 
der Strukturierung festgelegt. Sie widerspiegeln den hierar- 
chischen Zusammenhang der Strukturkomponenten (Dezimalklassi- 
fikation). 


Jede Aufgabenstrukturkomponente wird durch einen fachspezifi- 
schen Ausdruck benannt. 


Relationen, welche durch die baumartige Aufgabenstruktur ab- 
gebildet sind, heißen 


a) "BESTEHT AUS" H und 
b) "IST KOMPONENTE VOR" A je 


Die Relation "BESTEHT AUS" ist nicht mit der Relation "RUFT 
AUF" zu verwechseln: 
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Relation reflektiert 

"BESTEHT AUS" statische Struktur 
(Aufbauorganisation), 

"RUFT AUF" dynamische Struktur 
(Ablauforganisation). 


4.1.2. Teilaufgabenbeschreibung 


Erforderlich ist, jede Komponente der Aufgabenstruktur (Teil- 
aufgabe) in Textform zu beschreiben ("WAS ist zu tun; welche 
Bedingungen sind zu beachten?"). 


Dokumentation: Kurzbeschreibung der Teilaufgaben. 


4.1.3. Schnittstellenbestimmung 


Ergebnis des Arbeitsschrittes "Aufgabendekomposition" 
(Schritt 010) ist 


a) ein Aufgabenstrukturdiagramm, 
b) eine Teilaufgabenbeschreibung für 
jede Strukturkomponente. 


Prüfung des Ergebnisses: "Autor-Leser-Zyklus" 
(im Sinne: POS-Entwickler/POS-Nutzer). 


4.1.4. Möglichkeiten zur Rechnerunterstützung 
Wir orientieren auf folgende Möglichkeiten: 


a) Speicherung und Verwaltung der Aufgaben- 
struktur sowie der Teilaufgabenbeschreibung, 

b) Dokumentationserstellung unter verschiedenen 
Auswertungsgesichtspunkten der gespeicherten 
Aufgabenstruktur sowie der Teilaufgabenbe- 


schreibungs 
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PRÄZISIERTE ZIEL- UND AUFGABEN- 
STELLUNG ZUR POS-ENTWICKLUNG 


AUFGABENDEKOMPOSITION 


010.1. AUFGABENSTRUKTURLERUNG 


010.2. TEILAUFGABENBESCHREIBUNG 
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4.2. Anforderungsspezifikation 


Für jede Aufgabenstrukturkoömponente sind. die Anforderungen 
zu spezifizieren, welche sich aus der Sicht der EDV-An- 
wendung zur Aufgabenerfüllung ergeben. 


Zu bestimmen sinä: 


a) geforderte Ausgabedaten (A), 

b) erforderliche Eingabedaten (E), 

c) erforderliche, Verarbeitungsprozesse (V), 
d) operationelle Anforderungen. 


Methodisch wird so vorgegangen, daß zuerst die geforderten 
Ausgabedaten zu bestimmen sind. 


Der Informationsbedarf der POS-Nutzer wird somit als 
Ausgangspunkt für die Anforderungsspezifikation gewählt. 


Aus dem Informationsbedarf wird abgeleitet, welche Eingabe- 
daten erforderlich sind und welche Verarbeitungsprozesse 
zur Transformation der Eingabedaten in die Ausgabedaten 
ablaufen nüssen. 


Zusätzlich zu E, A und V werden operationelle Anforderungen 
ermittelt. 


4.2.1. Bestimmen der Ausgabedaten 


Die geforderten Ausgabedaten werden schrittweise bestimmt. 
Zwei Schritte sind vorgesehen: 


a) Je Aufgabenstrukturkomponente sind die Ausgabedaten hin- 
sichtlich inhaltlicher Zusammengehörigkeit in aggre- 
gierter Form zu bestimmen (z. B. Bestandsveränderungs- 
daten, Nettolohndaten). Diese Datenaggregationen werden 
els Datengruppen bezeichnet. 


b) Die zu jeder Datengruppe gehörenden Datenelemente werden 
bestimnt. 


020.1. 
020 .2. 
020 . 3. 


020.4. 
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ANFORDERUNGSSPEZIFIKATION 


BESTIMMEN DER AUSGABEDATEN 
BESTIMMEN DER EINGABEDATEN 


BESTIMMEN DER VERARBEITUNGSPROZESSE 


BESTIMMEN OPERATIONELLER ANFORDERUNGEN 
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4.2.2. Bestimmen der Eingabedaten 


In einem ersten Schritt sind die Eingabedatengruppen zu 
bestimmen, welche im zweiten Schritt in Datenelemente auf- 
gelöst werden (vgl. Abschn. 4.2.1.). 


4.2.3. Bestimmen der Verarbeitungsprozesse 


Für jede Aufgabenstrukturkomponente wird der erforderliche 
Verarbeitungsprozeß hinsichtlich wesentlicher Arbeitsschritte 
bestimmt und in Textform beschrieben ("WAS'"-Beschreibung), 


Die Verarbeitungsschritte sind in der Reihenfolge anzugeben, 
in welcher die Verarbeitung erfolgt (Numerierung der 
Verarbeitungsschritte). 


Zu beachten ist, daß die Beschreibung der Verarbeitungslogik 
(Algorithmus) im Arbeitsschritt 030.1. erfolgt. 

4.2.4. Bestimmen operationeller Anforderungen 

Zu bestimmen sind 

a) die Menge der zu verarbeitenden Daten (Mengengerüst), 

b) zeitliche Anforderungen (Frequenz der Verarbeitung). 
4.2.5. Schnittstellenbestimmung 

Die Schnittstelle S2 ist wie folgt zu charakterisieren: 

Auf einem jeweils gleichen Abstraktionsniveau stehen 
Datenstrukturen und Verarbeitungsprozesse in Beziehung: 


a) Datenstrukturen werden als Ausgangspunkt zur Bestimmung 
der Verarbeitungsprozesse gewählt (DeV, "daten- 
orientierter Entwurf"), 


b) Verarbeitungsprozesse (Datentransformationen, Funktionen) 
bilden den Ausgangspunkt des Entwurfs ("funktions- 
orientierter Entmurf"), 


c) Datenstrukturen und zugehörige Verarbeitungsprozesse 
werden als Einheit betrachtet. Zulässige Operationen auf 
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den Datenstrukturen sind vorgegeben (Konzept "Abstrakter 
Datentyp"). 


Die genannten Beziehungen sind Ausdruck des Verhältnisses 
"Teil - Gesamtheit": Datenstrukturen und Verarbeitungs- 
prozesse existieren einerseits relativ selbständig; anderer- 
seits besteht ein problembezogener Zusammenhang, welcher 
über festgelegte Schnittstellen herzustellen ist. 


Die relative Selbständigkeit erfordert eine Vorgabe, welche 
sowohl für die Bestimmung der Datenstrukturen als auch für 
die der Verarbeitungsprozesse verbindlich ist. 


Eine. derartige Vorgabe liegt als Ergebnis des Arbeits- 
schritts 020 vor: die Ein- und Ausgabedaten der einzelnen 
Strukturkomponenten wurden bestimat; die wesentlichen Ver- 
arbeitungsschritte inhaltlich festgelegt. 


Dokumentation der Anforderungsspezifikation (grafisch): 
HIPO-Übersichtsdiagrann. 


Prüfung: "Autor-Leser-Zyklus." 


4.2.6. hKöglichkeiten zur Rechnerunterstützung 


Als Ergebnis des Arbeitsschrittes 020 liegt die Ergänzung 
einer jeden Aufgabenstrukturkomponente um eine Spezifikation 
datenverarbeitungsorientierter Anforderungen zur Aufgaben- 
erfillung vor. 


Wir orientierten darauf, die im Arbeitsschritt OlO gespei- 
cherten Tellaufgabenbeschreibungen um die jeweilige 
Anforderungsspezifikation zu ergänzen. 


Teilaufgabenbeschreibung und zugehörige Anforderungs- 
spezifikation bilden somit eine aufgabenbezogene Beschreibungs- 
einheit (ABE), welche für eine rechnerunterstützte Bearbei- 
tung vorgesehen ist. 


Ergebnis; 





Bestimmung 
erforderlicher 
Ein- und 
Ausgabedaten 


Voraussetzung 


SPEZIFIKATION 
DER j 
DATENSTRUKTUREN 
(030) | 





ANFORDERUNGSSPEZIFIKATION 
(020) 





DER 






Bestimmung 
wesentlicher 
Verarbeitungs- 
schritte 





SPEZIFIKATION 





VERARBEITUNGS-- 
PROZESSE - 
(040) 








L_ nn 


konzept 


29 


4.2. Spezifikation der Datenstrukturen 


Die Beschreibung der folgenden Arbeitsschritte erfordert, 
einige Begriffe zu bestimmen. 


Hinsichtlich der Zuordnung von Daten zu einem Verarbeitungs- 
prozeß oder zu mehreren Verarbeitungsprozessen unterscheiden 
wir lokale und globale Daten. 


Lokale Daten ordnen wir einer bestimmten Aufgabe (im Sinne 
Teilaufgabe), einem bestimmten Verarbeitungsprozeß zu 
("lokale Datensicht", z. B. im datenorientierten Entwurf 
von Anwendungsprogrammen nach JACKSON). 


Globale Daten sind gemeinsame Ressource unterschiedlicher 
Verarbeitungsprozesse (klobale Dateneicht"). Eine 
zentralisierung der Daten im Hinblick auf unterschiedliche 
Verarbeiltungsprozesse wird vielfach angestrebt (Anwendungs- 
programme in Datenbanksystemen - vgl. WEDEKIND). 


Zur Spezifikation der Datenstrukturen verwenden wir als 
theoretische Basis das Abstraktionsstufenkonzept. 


Wir verweisen auf Vorschläge zur Standardisierung, welche 
bei Anwendung von Datenbanksystemen auf eine "Drei-Ebenen- 
Architektur" zielen (ANSI/SPARC, CODASYL): 


ANSI/SPARC CODASYL 





Externes Schema Subschenma 
(External scheme) 


Konzeptuelles Schema Schena 
(Conceptual schenma) 


Internes Schena Speicherschema 
(Internal schema) (Storage schena). 


(u2stsAyd‘TexX0oT) 

(SI)YNIHOS SANUALNI 4yOTsTTaL 
(SY) VNAHOS (UOBT3oT‘T8q0T2) 

2 SYTITYANLIAZNOY 4UOTB4UBB3H 
(y9ST3oT*TEXOT) 

(SI)VNIHDS SANUHLXH AyUOTSTTaL 





yaınp Zumqrazyosag +yoTs 


SIesy 21) *ÜsSIe—sy al 





ER 
= 
I 
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4.3.1. Bestimmen lokaler Datenstrukturen 


Aus der Sicht einer jeden Teilaufgabe (Einzelanwendung) ist 
eine Strukturierung der im Schritt 020 bestimmten Ein- und Aus- 
gabedaten vorzunehmen. 


Entwurfsniveau: logisch; Sicht: lokal. 


Zur Beschreibung der Datenstruktur sind grafische und formal- 
sprachliche Mittel anwendbar. 


wir geben folgende Orientierung: 
Beschreibung Mittel 





Grafisch Symbolik zur Datenstrukturnotation 
in Diagramnforn (vgl. JACKSON), 


Formalsprachlich Relationales Datenmodell (vgl. CODD). 


Alternative Vorgehensweisen: 


a) Die Diegramm-Notation wird im datenorientierten Entwurf 
von Anwendungsprogrammen nach JACKSON (D=®V) genutzt. 


Ergebnis des Teilschritts 030.1.: Ein- und Ausgabedaten- 
strukturen der Einzelanwendungen. \ 


Entwurfsfortsetzung: Teilschritt 040.1. 


b) Die relationale Datenbeschreibung kann als Ausgangspunkt 
der Datenbasisstrukturierung für eine gegebene EDV-Anwendung 


genutzt werden. 


Ergebnis des Teilschritts 030.1: Relationale Datenbeschreibung 
der Einzelanwendungen. 


Entwurfsfortsetzung: Teilschritt 030.2. 
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4.3.2. Strukturieren der Datenbasis 
und Bestimmen der Zugriffspfade 


Für eine gegebene EDV-Gesamtanwendung ist die Datenbasis 
zu bestimmen und zu strukturieren, 

Bevorzugte Auswertungen der in Dateien zu organisierenden 
Datenelemente sind festzulegen (Zugriffspfadbestimmung). 
Die im Teilschritt 020.4. ermittelten operationellen 
Anforderungen sind zu beachten. 


Entwurfsniveau: logisch; Sicht: global. 


Alternative Vorgehensweisen: 


a) Teilaufgabenabhängige Datenbasisstrukturierung 


Ausgangspunkt: Datensicht der Finzelanwendungen (Teilaufgaben) 
als Ergebnis von Teilschritt 030.1. 


Vorgehen: Teilsicht (030.1.) —ge Gesantsicht (030.2.). 
b) Teilaufgabenunabhängige Datenbasisstrukturierun 


Ausgangspunkt: Datensicht der Gesamtanwendung (konzeptuelles 
Schena). 


Vorgehen: Gesamtsicht (030.2.) —» Teilsicht (030.1.). 


Zur methodischen Unterstützung des Teilschritts 030.2. 

orientieren wir auf Anwendung 

- der Matrixmethode, 

- von Methoden zur Datenstrukturierung nach funktionellen 
Abhängigkeiten von Datenelementen. 


Entwurfsfortsetzung: Teilschritt 030.3. 


4.3.3. Bestimmen der Datei- und Speicherungsstrukturen 


Ausgehend von den Ergebnissen des Teilschritts 030.2. sind 
effektive Datei- und Speicherungsstrukturen! ) zu bestimmen, 


T) Der Begriff "Speicherungsstruktur" wird angewendet, um die 
gespeicherten logischen Beziehungen zwischen physischen 
Sätzen zu charakterisieren. 


Der Begriff "Dateistruktur" soll zur Charakteristik des 
detatliierten Datelaufbaus verwendet werden. 
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welche mit programmtechnischen Mitteln gegebener Betriebs- 
systeme -— das sind allgemeine oder Datenbankbetriebssysteme - 
implementiert werden können. 


Entwurfsniveau: physischs3 Sicht: lokal, global 


Ein Datenbankbetriebssystem nimmt in der Praxis betriebs- 
wirtschaftlich orientierter EDV-Anwendungen der DDR eine 
hervorragende Stellung ein: das PS DES/R. 


Auf dieses Datenbankbetriebssysten wird nit den folgenden 
Ausführungen Bezug genomnen. 


Zur Bestimmung von Datei- und Speicherungsstrukturen unter 
den Bedingungen der Anwendung des PS DBS/R lassen sich 
typische Aufgaben angeben. Das sind vor allen: 

l. Gestalten eines. Dateikonzepts 


- Klassifizieren der gruppierten Datenelemente nach 
logischen Unabhängigkeiten bzw. Abhängigkeiten, ent- 
sprechende Zuordnung zu Basis- und Verbindungsdateien 
(ED, VD) 


- Bestimmen der Basisdateien und deren hierarchische 
Beziehungen untereinander 


-— Bestimmen der Verbindungsdateien und deren hierarchische 
Beziehungen untereinander 


-— Bestimmen von Haupt- und Nebenoränungskriterien der 
Dateien 


-— Bestimmen der Satzarten je Datei 
- Bestimmen separater Dateien 


- Festlegen der Dateiverarbeitungsformen, 
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2. Bestimmen der Realisierungsart logischer Beziehungen 
zwischen den Dateien 


- Bestimmen der Verkettung (Prinär-/Sekundärketten, 
Verkettungsrichtung, Sortierbegriffe) 


Kopplungen 


Indizierung 


logische Verbindungen, 

3. Prüfen der Speicherungsstruktur (Funktionsfähigkeit, 
Vollständigkeit, Effizienz), 

4. Dokumentieren der Speicherungsstruktur (Datenbankdiagramn), 

5. Bestimmen des detaillierten DB-Dateiaufbaus, 

6. Bestimmen der Feldbehandlungen, 


7. Formalisierte Beschreibung der Datei- und Speicherungs- 
struktur, 


4.3.4. Schnittstellenbestimmung 


Ergebnis des Arbeitsschritts 030 ist eine formalisierte 
Beschreibung der Datei- und Speicherungsstrukturen als 
Voraussetzung für die sich anschließende Implementierung. 


4.3.5. Möglichkeiten zur Rechnerunterstützung 


Programmtechnische Mittel zur Unterstützung des Arbeits- 
schritts 030 werden bei Anwendung des PP Dateikatalog OS/ES 
und des PS DBS/R bereitgestellt. 


wir orientieren darauf, Dialogprogramme zur formalisierten 
Beschreibung von Datei- und Speicherungsstrukturen zu 
entwickeln. Dizse Orientierung hat zum Ziel, das "Ausfüllen" 
der gegenwärtig .angewendeten Dateikennblätter als Bildschirm- 
dialog zu gestalten. 
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SPEZIFIKATION DER DATENSTRUKTUREN 


030.1, BESTIMMEN LOKALER DATENSTRUKTUREN 


030.2. STRUKTURIEREN DER DATENBASIS 
UND BESTIMMEN DER ZUGRIFFSPFADE 


030.3, BESTINMEN DER DATEI- 
UND SPEICHERUNGSSTRUKTUREN 





IMPLEMENTIERUNG 
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Weiterhin orientieren wir auf 

die Möglichkeit der Generierung von Definitionsanweisungen 
für das Zielprogramm aus den gespeicherten Datenbeschreibungen 
(Transformation für Schnittstelle S3). 


4b, Spezifikation der Verarbeitungsprozesse 
4.4.1. Algorithmenentwurf 


Ausgehend von den im Arbeitsschritt 020 entwickelten 
Anforderungsspezifikationen sind die Algorithmen für die 
einzelnen Verarbeitungsprozesse zu erarbeiten. 


Entwurfsniveau: logisch; Sicht: lokal. 


Zur Ererbeitung der Algorithmen orientieren wir auf die 
Anwendung jener Methoden und Techniken, welche für einen 
strukturierten Entwurf geeignet sind. 


Entsprechend dem gegenwärtigen Erkenntnisstand sind das die 


- JACKSON-Methode, 
- Struktogramnm-NMethode (NASSI-SHNEIDERMAN), 
- Entscheidungstabellen-Methode, 


Ergebnis des Teilschritts 0O40.1.: Formalsprachliche 
(Pseudokodes, Entscheidungstabellen) oder grafische 
(Struktogramme) algorithmische Beschreibung der einzelnen 
Verarbeitungsprozesse. 


Entwurfsfortsetzung: Teilschritt 040.2. 
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1 040 SPEZIFIKATION DER VERARBEITUNGSPROZESSE 


040.1. ALGORITHMENENTWURF 


040.2. STRUETURIEREN DER PROGRANMBASIS 
UND BESTIMMEN DER ABLAUFSTEUERUNG 


040.3. MODULENTWURF 





IMPLEMENTIERUNG 
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4.4.2. Strukturieren der Programmbasis 
und Bestimmen der Ablaufsteuerung 


Die Menge der im Teilschritt 040.1. erarbeiteten Algorithnen 
der einzelnen Verarbeitungsprozesse ist Ausgangspunkt zur 
Bestimmung und Strukturierung der Programmbasis für die 
gegebene EDV-Gesamtanwendung. 


Komponenten der Programmbasis können sein: 


- Programmsystene, 
- Programme, 
- Moduln . 


Elementarkomponenten der Programmbasis sind Moduln, 
Programme und Programmsysteme sind aggregierte Komponenten. 


Für die genannten Komponenten ist unter dem Aspekt der 
Programmabarbeitung (dynamischer Aspekt) eine Ablaufsteuerung 
zu bestimmen. 

wir orientieren auf eine hierarchische Programmstrukturierung 
und -ablaufsteuerung ). 


Entwurfsniveau: logisch; Sicht: global. 


Ergebnis des Teilschritts O40.2.: Komponenten der Progrann- 
basis für die gegebene EDV-Gesamtanwendung sowie deren 
strukturelle Beziehungen einschließlich Ablaufsteuerung. 


Entwurfsfortsetzung: Teilschritt 040.3. 





1) Für die Aufgabenklasse der satzweisen seq. Verarbeitung 
von Dateien wird häufig auf eine normierte Progrann- 
rn und -ablaufsteuerung ('"Normierte Programmierung") 
orientiert, 
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4.4.3. Modulentwurf 


Ausgehend von dem Ergebnis des Teilschritts 040.2. ist ein 
detaillierter Modulentwurf? durchzuführen, 

Gegenstand des Modulentwurfs sind Modulspezifikation und 
Logikbeschreibung. 


Ein tWypisierter Modulaufbau wird angestrebt, wobei Modul- 
schnittstellen (Interface) zu vereinheitlichen und Nodul- 
verkniipfungen zu ermöglichen sind. 


Entwurfsniveau: physisch; Sicht: lokal. 

Ergebnis des Teilschritts 040.3.: Detaillierter Modulentwurf 
als Programmiervorgabe für die sich anschließende 
Implementierung (Schnittstelle S4). 

4.4.4. Möglichkeiten zur Rechnerunterstützung 

wir orientieren auf folgende Möglichkeiten: 


Speicherung und Verwaltung von Pseuäokodes, 
Dokumentationserstellung, 

Generieren von Zielprogramnmen bzw. Zielprogrammrahmen aus 
Pseudokodes, 

- Entscheidungstabellenvorübersetzung., 


Die beiden letztgenannten Möglichkeiten zur Rechnerunter- 
stützung sind Beispiek für Transformationen von Ergebnissen 
des Arbeitsschritts O4O in die Ebene der programmtechnischen 
Implementierung. 


1) Wir verwenden den Modulbegriff für programmtechnische 
Einheiten unter dem Aspekt der Implementierung. 


